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Final Action 
Response to Amendment 

1 . Applicant's Remarks/ Arguments filed on 1 1/5/2007 regarding claims 1-39 have been 
considered. Claims 1-39 are currently pending. 

Claim Rejections - 35 USC § 102 
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed in the United States before 
the invention by the applicant for patent or (2) a patent granted on an application for patent by another filed in the United States before the 
invention by the applicant for patent, except that an international application filed under the treaty defined in section 351(a) shall have the 
effects for purposes of this subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 2 1 (2) of such treaty in the English language. 

2. Claims 1-5, 7, 9-12, 13-19, 21-25, 26-36, 38-39 are rejected under 35 U.S.C. 102(e) as 
being anticipated by Goldszmidt et al. (USP 6,195,680). 

Regarding claim 1, Goldszmidt discloses a context-selection mechanism for selecting a 
context (selecting a streaming server based on size, capacity, location/affinity, network 
connectivity and utilization rate, see col. 4, lines 26-67, col. 5, lines 1-3, 55-64 and Fig. la) 
from a pool of contexts (from a pool of clusters 1.5 and 1.6, Fig. la) for processing a data 
packet (for processing packet information via the Internet, see col. 5, lines 23-49) 
comprising: 

an interface receiving a data packet (source station for receiving audio and video 
packets, Figs. 6-8) and communicating with a multi-streaming processor (for communicating 
with server architecture, see elements 1,7, 1.8, Fig. la) said multi-streaming processor (server 
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architecture, see element 1.7, Fig. la) hosting the pool of contexts (the pool of clusters of 
streaming servers, see element 1.2, 1.3, 1.5, 1.6, Fig. la); 

circuitry (control server 2.1, Fig. la) for computing input data into a result value 
according to logic rule (for computing number of connection streams to each streaming 
server, see col. 8, lines 44-54) and for selecting a context based on the computed value (for 
selecting a server based on the computed number of connection streams to each streaming 
server, see col. 8, lines 44-54); and 

a loading mechanism for preloading packet information from the received data packets 
into the selected context (audio and video inputs received at the source station are 
captured/converted from analog to digital form, compressed, and packetized at a capture 
station, and then stored in circular buffer queues contained in a reflector/streaming server, 
see col. 15, lines 14-43) for subsequent processing (for subsequent processing by the reflector, 
see col. 15, lines 29-43; reflector will later produce a new copy of the circular buffer queue for a 
connection to a new client station); 

characterized in that the computation of the input data functions (the computation of the 
number of streaming connections to each streaming server, see col. 8, lines 44-54) to enable 
identification and selection of a best context for processing the packet information according to 
the logic rule at the instant time (enables the identification and selection of a streaming server 
for processing the multimedia data packets received from the source station, see col. 8, lines 
44-54 and Figs. 6-8) such that a multitude of context selections made over a period of time 
(based on the number of connection streams to each streaming server, see col. 8, lines 44- 
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54) facilitates balancing of load pressure on functional units (streaming servers) housed within 
the multi-streaming processor and required for packet processing (facilitates load balancing on 
the streaming servers housed within the server architecture required for streaming 
multimedia packets to clients, see col. col. 8, lines 44-54). 

Regarding claim 2, Goldszmidt discloses the context-selection mechanism of claim 1 
integrated to a data packet router (selection of a streaming server integrated to the control 
server 1.1, which is a TCP router, see col. 4, lines 54-67, col. 5, lines 1-3) operating in a data- 
packet-network (operating in the Internet, see col. 5, lines 22-31). 

Regarding claim 3, Goldszmidt discloses the context-selection mechanism of claim 2 
wherein the data-packet- network is the Internet network (the Internet, see col. 5, lines 22-31). 

Regarding claim 4, Goldszmidt discloses the context-selection mechanism of claim 1 
wherein the pool of contexts (the pool of clusters of streaming servers, Fig. la) is divided into 
separate clusters (separates clusters 1.5, 1.6, Fig. la) in the processing unit (server 
architecture, see element 1.7, Fig. la), each cluster containing some of the functional units used 
in packet processing (each cluster contains streaming servers used in streaming packets, col. 
4, lines 26-58 and Fig. la). 

Regarding claim 5, Goldszmidt discloses the context-selection mechanism of claim 1 
wherein the input data into the computation circuitry includes availability information of 
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individual ones of the pool of contexts at the time of computation (real-time information of the 
unavailability of a streaming server based on determining that the received bit rate, see col. 
10, lines 1-18), 

Regarding claim 7, Goldszmidt discloses the context-selection mechanism of claim 5 
wherein the input data into the computation circuitry further includes statistical data about 
previous processing time periods required to process similar data packets (the previous routing 
request or affinity data records stored at the control server are used by the control server 
to select a server to process a client request in accordance with these affinity data records, 
see col. 6, lines 40-60). 

Regarding claim 9, Goldszmidt discloses the context-selection mechanism of claim 1 
wherein the input data is sourced from the multi-streaming processor (control server 1.1 of the 
server architecture 1.7 monitors the number of connection streams to a streaming server, 

see col. 8, lines 44-54). 

Regarding claim 10, Goldszmidt discloses the context-selection mechanism of claim 1 
wherein the input data is sourced from a third party (a client detects load imbalances, see col. 3, 
lines 6-11). 

Regarding claim 11, Goldszmidt discloses the context-selection mechanism of claim 4 
wherein the clusters are numbered (clusters are numbered, see col. 4, lines 26-40 and Fig, la) 
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and the functional units are distributed symmetrically therein (streaming servers are 
distributed symmetrically as even numbers in one cluster, see col. 4, lines 26-40 and Fig. 
la). 

Regarding claim 12, Goldszmidt discloses the context-selection mechanism of claim 4 
wherein the clusters are numbered (clusters are numbered, see col. 4, lines 26-40 and Fig, la) 
and the functional units are distributed asymmetrically therein (servers are distributed 
asymmetrically as even numbers in one cluster and odd numbers in another cluster, see col. 
4, lines 26-40). 

Regarding claim 13, Goldszmidt discloses a system for load balancing pressure on 
functional units (load balancing for streaming servers in each cluster) within a multi- 
streaming processor (server architecture, Fig. la) during the processing of multiple data 
packets (for processing packet information via the Internet, see col. 5, lines 23-49) 
comprising: 

a context-selection mechanism having a communication interface (source station, Figs. 

6-8); 

circuitry for computing input data (control server 2.1, Fig. la) according to a logic rule 
(for computing number of connection streams to each streaming server, see col. 8, lines 44- 
54) and a mechanism for preloading packet information from a data packet received from the 
communication interface into available ones of a pool of contexts (a mechanism that audio and 
video inputs received at the source station are captured/converted from analog to digital 
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form, compressed, and packetized at a capture station, and then stored in circular buffer 
queues contained in a reflector/streaming server, see col. 15, lines 14-43); 

a multi-streaming processor core (server architecture, see element 1.7, Fig. la) 
responsible for processing the data packets (for processing packet information via the 
Internet, see col. 5, lines 23-49), the processor core hosting the functional units (server 
architecture hosing a plurality of streaming servers, see element 1.7, Fig. la) and the context 
pool (the pool of clusters of streaming servers, see element 1.2, 1.3, 1.5, 1.6, Fig. la); and 

a set of instructions comprising the one or more logic rules governing context selection 
(for computing number of connection streams to each streaming server, see col. 8, lines 44- 
54), wherein packet processing pressure upon the functional units within the processor core is 
balanced by selecting individual contexts for processing packet information received from the 
communication interface based at least in part on the value (load balancing on the streaming 
servers housed within the server architecture required for streaming multimedia packets 
the received data packets received from the source station based on the number of 
connection streams to each streaming server, see col. 8, lines 44-54). 

Regarding claim 14, Goldszmidt discloses the context-selection mechanism of claim 13 
integrated to a data packet router (selection of a streaming server integrated to the control 
server 1.1, which is a TCP router, see col. 4, lines 54-67, col. 5, lines 1-3) operating in a data- 
packet-network (operating in the Internet, see col. 5, lines 22-31). 
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Regarding claim 15, Goldszmidt discloses the context-selection mechanism of claim 14 
wherein the data-packet- network is the Internet network (the Internet, see col. 5, lines 22-31). 

Regarding claim 16, Goldszmidt discloses the context-selection mechanism of claim 13 
wherein the pool of contexts (the pool of clusters of streaming servers, Fig. la} is divided into 
, separate clusters (separates clusters 1.5, 1.6, Fig. la) in the processing core (server 
architecture, see element 1.7, Fig. la), each cluster containing some of the functional units used 
in packet processing (each cluster contains streaming servers used in streaming packets, col. 
4, lines 26-58 and Fig. la). 

Regarding claim 17, Goldszmidt discloses the context-selection mechanism of claim 13 
wherein the input data into the computation circuitry includes availability information of 
individual ones of the pool of contexts at the time of computation (real-time information of the 
unavailability of a streaming server based on determining that the received bit rate, see col. 
10, lines 1-18). 

Regarding claim 18, Goldszmidt discloses the context-selection mechanism of claim 13 
wherein the input data into the computation circuitry further includes real time information of 
any processing streams stalled in un-available ones of the pool of contexts (real-time 
information of the failure of a streaming server based on determining that the received bit 
rate, see col. 10, lines 1-18) and the reason for the stall (when the bit rate is below a threshold, 
see col. 10, lines 1-18). 
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Regarding claim 19, Goldszmidt discloses the context-selection mechanism of claim 13 
wherein the input data into the computation circuitry further includes statistical data about 
previous processing time periods required to process similar data packets (delivery rate is based 
using server time stamps, see col. 10, lines 49-63). 

Regarding claim 21, Goldszmidt discloses the context-selection mechanism of claim 13 
wherein the input data is sourced from the multi-streaming processor (control server 1.1 of the 
server architecture 1.7 monitors the number of connection streams to a streaming server, 
see col. 8, lines 44-54) and provided in a software table (affinity tables, col. 6, lines 48-60). 

Regarding claim 22, Goldszmidt discloses the context-selection mechanism of claim 13 
wherein the input data is sourced from a third party (a client detects load imbalances, see col. 3, 
lines 6-11). 

Regarding claim 23, Goldszmidt discloses the context-selection mechanism of claim 16 
wherein the clusters are numbered (clusters are numbered, see col. 4, lines 26-40 and Fig, la) 
and the functional units are distributed symmetrically therein (streaming servers are 
distributed symmetrically as even numbers in one cluster, see col. 4, lines 26-40 and Fig. 
la). 
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Regarding claim 24, Goldszmidt discloses the context-selection mechanism of claim 16 
wherein the clusters are numbered (clusters are numbered, see col. 4, lines 26-40 and Fig, la) 
and the functional units are distributed asymmetrically therein (servers are distributed 
asymmetrically as even numbers in one cluster and odd numbers in another cluster, see col. 
4, lines 26-40). 

Regarding claim 25, Goldszmidt discloses the system of claim 13 wherein the set of 
instructions comprising the logic rule is programmable (see col. 9, lines 23-34). 

Regarding claim 26, Goldszmidt discloses a method for load balancing pressure on 
functional units (streaming servers, elements 1.2, 1.3, Fig. la) contained within a multi- 
streaming processor core (server architecture, see Fig. la) during processing of multiple 
data packets (for processing packet information via the Internet, see col. 5, lines 23-49) 
comprising steps of: 

(a) arranging the functional units (streaming servers, Fig. la) into more than one 
separate cluster (clusters, see elements 1.5, 1.6, Fig. la) on the core of the processor (on the 
core of the server architecture, element 1.7 Fig. la), each cluster (each cluster, Fig. la) 
containing an equal number of contexts (equal number of odd and even streaming servers, 
Fig. la) that may write to the functional units (streaming servers) within the hosting cluster 
(streaming servers within each cluster, see Fig. la); 

(b) receiving a data packet for processing (receiving data packets at the source station, 
see Figs. 6-8); 
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(c) receiving as input for computation, data about the instant availability status of 
individual contexts within each cluster (real-time information of the unavailability of a 
streaming server within each cluster based on determining that the received bit rate, see 

col. 10, lines 1-18); 

(d) receiving as input for computation, data about stream status of streams occupying any 
contexts within each cluster (receiving current number of connection streams to each 
streaming server, see col. 5, lines 44-54); and 

(e) computing the data received as input to produce a value (the computation of the 
number of streaming connections to each streaming server, see col. 8, lines 44-54), the value 
identifying and initiating selection of a context for processing packet information from the 
received data packet(the number of streaming connections enables the identification and 
selection of a streaming server for processing the received data packets, see col. 8, lines 44- 
54 and Figs. 6-8) and balancing packet processing load of the functional units within each cluster . 
(load balancing on the streaming servers housed within the server architecture required for 
streaming multimedia packets to clients, see col. col. 8, lines 44-54); and 

(f) preloading packet information from the received data packets into the selected context 
(audio and video inputs received at the source station are captured/converted from analog 
to digital form, compressed, and packetized at a capture station, and then stored in circular 
buffer queues contained in a reflector/streaming server, see col. 15, lines 14-43) for 
subsequent processing (for subsequent processing by the reflector, see col. 15, lines 29-43; 
reflector will later produce a new copy of the circular buffer queue for a connection to a new 
client station); 
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(g) repeating steps (b) through (f) for each of the multiple data packets for processing 
(continuous multimedia stream processing, see col. 3, lines 12-26). 

Regarding claim 27, Goldszmidt discloses the method of claim 26 integrated to a data 
packet router (selection of a streaming server integrated to the control server LI, which is a 
TCP router, see col. 4, lines 54-67, col. 5, lines 1-3) operating in a data-packet-network 
(operating in the Internet, see col. 5, lines 22-31). 

Regarding claim 28, Goldszmidt discloses the method of claim 27 wherein the data- 
packet- network is the Internet network (the Internet, see col. 5, lines 22-31). 

Regarding claim 29, Goldszmidt discloses the method of claim 26 wherein in step (a) the 
functional units are provided within each cluster in a symmetrical fashion (streaming servers 
are distributed symmetrically as even numbers in one cluster, see col. 4, lines 26-40 and Fig. 
la). 

Regarding claim 30, Goldszmidt discloses the method of claim 26 wherein in step (a) the 
functional units are provided within each cluster in an asymmetrical fashion (streaming servers 
are distributed asymmetrically as odd numbers in one cluster, see col. 4, lines 26-40 and Fig. 
la). 
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Regarding claim 31, Goldszmidt discloses the method of claim 26 wherein in step (b) the 
packet is received at a data port of a data router and requires automatic activation (packet is 
received at the address of the control server, see col. 4, lines 65-67, col. 5, lines 1-3). 

Regarding claim 32, Goldszmidt discloses the method of claim 26 wherein in step (b) the 
packet is held by the processor and requires a context for processing (automatically switching 
clients among multiple streaming servers, see col. 9, lines 66-67, col. 10, lines 1-3). 

Regarding claim 33, Goldszmidt discloses the method of claim 26 wherein in step (c) 
availability status comprises an indication of which one of two components owns each context 
(indicating whether even numbered ports primary streaming servers or odd numbered 
ports alternate streaming servers takes the responsibility to serve client requests, see col. 9, 
lines 7-22). 

Regarding claim 34, Goldszmidt discloses the method of claim 33 wherein in step (c) one 
of the components is the processor (streaming server 3.2) and other component is a packet 
management unit (alternate streaming server 3.7, Fig. 3). 

Regarding claim 35, Goldszmidt discloses the method of claim 26 wherein in step (d) the 
data about stream status includes whether or not streams are stalled within any of the contexts 
(real-time information of the failure of a streaming server based on determining that the 
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received bit rate, see col. 10, lines 1-18) and the reason for the stall (when the bit rate is below 
a threshold, see col. 10, lines 1-18). 

Regarding claim 36, Goldszmidt discloses the method of claim 26 wherein in step (d) the 
data about stream status includes time parameters of how long each stream will take to process 
data packets associated with their contexts (delivery rate is based using server time stamps, 
see col. 10, lines 49-63). 

Regarding claim 38, Goldszmidt discloses the method of claim 26 wherein in steps (c) 
through (d) are practiced according to a set of rules of logic (see col. 10, lines 49-63). 

Regarding claim 39, Goldszmidt discloses the method of claim 39 wherein the rule of logic is 
programmable (see col. 9, lines 23-34). 



Claim Rejections - 35 USC §103 
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

3. Claim 6 is rejected under 35 U.S.C. 103(a) as being unpatentable over Goldszmidt et al. 



in view of Krum (USP 6,618,820). 
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Regarding claim 6, Goldszmidt discloses the context-selection mechanism of claim 5 
wherein the input data into the computation circuitry further includes real time information of 
any processing streams stalled in un-available ones of the pool of contexts (real-time 
information of the failure of a streaming server based on determining that the received bit 
rate, see col. 10, lines 1-18). 

Goldszmidt does not explicitly show the input data into the computation circuitry further 
includes the reason for the stall. 

However, Krum discloses an application server farm system that comprises a plurality of 
components, wherein if a failure is detected at one component, and the reason for the failure will 
be passed to other components (col. 13, lines 62-67, col. 14, lines 1-27, 45-67, col. 15, lines 1-8). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the load balancing method and system of Goldszmidt with the 
teaching of Krum in disclosing an application server farm system that comprises, a plurality of 
components, wherein if a failure is detected at one component, and the reason for the failure will 
be passed to other components such that the input data into the computation circuitry of 
Goldszmidt will further include the reason for the stall/failure. 

The motivation to do so is to dynamically allocate the appropriate resources to remedy 
the problem that contributes to the failure of a component. 

4. Claims 8, 20, 37 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Goldszmidt et al. in view of Zisapel et al. (USP 6,249,801) 
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Regarding claim 8, Goldszmidt discloses all the aspects of the claimed invention set forth 
in the rejection of claim 5 above, except fails to explicitly show the context-selection mechanism 
of claim 5 wherein the input data into the computation circuitry further includes statistical data 
about the distribution of instruction types associated with individual ones of previously 
processed and similar data packets. 

However, Zisapel discloses the request type from client can be DNS request or HTTP 
request (see col. 7, lines 52-61). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the load balancing method and system of Goldszmidt with the 
teaching of Zisapel in rerouting requests based on the type of request made by client such that 
the weighted value to determine which load balancer will be the best proximity network to 
respond to client's request is based on the distribution of what request type to be instructed by 
client. The motivation to do so is to enable redirecting the request to the appropriate location 
according to the type of request made by client during the determination of the best proximity 
network to client. 

Regarding claim 20, Goldszmidt discloses all the aspects of the claimed invention set 
forth in the rejection of claim 13 above, except fails to explicitly show the system of claim 13 
wherein the input data into the computation circuitry further includes statistical data about the 
distribution of instruction types associated with individual ones of previously processed and 
similar data packets. However, Zisapel discloses the request type from client can be DNS 



t 
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request or HTTP request (see col. 7, lines 52-61). Therefore, it would have been obvious to one 
of ordinary skill in the art at the time the invention was made to modify the load balancing 
method and system of Goldszmidt with the teaching of Zisapel in rerouting requests based on the 
type of request made by client such that the weighted value to determine which load balancer 
will be the best proximity network to respond to client's request is based on the distribution of 
what request type to be instructed by client. The motivation to do so is to enable redirecting the 
request to the appropriate location according to the type of request made by client during the 
determination of the best proximity network to client. 

Regarding claim 37, Goldszmidt discloses all the aspects of the claimed invention set 
forth in the rejection of claim 26 above, except fails to explicitly show the method of claim 26 
wherein in step (d) the data about stream status includes distribution parameters of instruction 
types that each stream has executed to process its data packet. 

However, Zisapel discloses the request type from client can be DNS request or HTTP 
request (see col. 7, lines 52-61). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the load balancing method and system of Goldszmidt with the 
teaching of Zisapel in rerouting requests based on the type of request made by client such that 
the weighted value to determine which load balancer will be the best proximity network to 
respond to client's request is based on the distribution of what request type to be instructed by 
client. The motivation to do so is to enable redirecting the request to the appropriate location 
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according to the type of request made by client during the determination of the best proximity 
network to client. 

Response to Arguments 
5. Applicant's arguments filed on 1 1/5/2007 with respect to claims 1, 6-7, 13, 26 have been 
considered but they are not persuasive. 

Applicant argued on page 2, paragraph 2 of the Remarks that Goldszmidt does not teach 
or suggest "a loading mechanism for preloading packet information from the received data 
packet into the selected context for subsequent processing," examiner respectfully disagrees. In 
response to the amended claim 1, it is noted that the source station (Figs. 6-8) now corresponds 
to the recited interface, and Goldszmidt discloses a loading mechanism for preloading the packet 
information into the selected context (audio and video inputs received at the source station 
are captured/converted from analog to digital form, compressed, and packetized at a 
capture station, and then stored in circular buffer queues contained in a 
reflector/streaming server, see col. 15, lines 14-43) for subsequent processing (for subsequent 
processing by the reflector, see col. 15, lines 29-43; reflector will later produce a new copy of 
the circular buffer queue for a connection to a new client station). Thus, Goldszmdit teaches "a 
loading mechanism for preloading packet information from the received data packet into the 
selected context for subsequent processing." 

Applicant also argued on page 2, paragraph 2 of the Remarks that Goldszmidt does not 
teach or suggest "balancing of load pressure is accomplished via a multitude of selections over 
time of the context used to process the same packet information from the received data packets," 
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examiner respectfully disagrees. Goldszmidt does teach enabling identification and selection of 
a best context for processing the data packet according to the logic rule at the instant time 
(enables the identification and selection of a streaming server for processing the 
multimedia data packets received from the source station, see col. 8, lines 44-54 and Figs. 6- 
8) a multitude of context selections made over a period of time (based on the number of 
connection streams to each streaming server, see col. 8, lines 44-54) facilitates balancing of 
load pressure on functional units (streaming servers) housed within the multi-streaming 
processor and required for packet processing (facilitates load balancing on the streaming 
servers housed within the server architecture required for streaming multimedia packets to 
clients, see col. col. 8, lines 44-54). 

In response to applicant's arguments on page 4, last paragraph of the Remarks that 
Goldszmidt does not teach or suggest "... statistical data about previous processing time periods 
required to process simitar data packets," as recited in claim 7, examiner respectfully disagrees. 
Applicant's rationale is based on the "how long a time period was required to process a packet." 
However, the features of the features upon which applicant relies (i.e., "how long a time period 
was required to process a packet") are not recited in the rejected claim 7. However, only "data 
about previous processing time periods required" is recited in the claim. Although the claims are 
interpreted in light of the specification, limitations from the specification are not read into the 
claims. See/« re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). 

In light of the foregoing, Claims 1-5, 7, 9-12, 13-19, 21-25, 26-36, 38-39 are rejected 
under 35 U.S.G. 102(e) as being anticipated by Goldszmidt et al. (USP 6,195,680), Claim 6 is 
rejected under 35 U.S.C. 103(a) as being unpatentable over Goldszmidt et al. in view of Krum 
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(USP 6,618,820), and Claims 8, 20, 37 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Goldszmidt et al. in view of Zisapel et al. (USP 6,249,801). 



Conclusion 

6. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 
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7. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Kevin Mew whose telephone number is 571-272-3141. The 
examiner can normally be reached on 9:00 am - 5:30 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Chi Pham can be reached on 571-272-3179. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 




